[Shipping Labels] Fix purchased labels not presenting destination address #15866

RafaelKayumov · 2025-07-03T22:54:06Z

Fix: Display destination address for purchased shipping labels

Description

This pull request fixes a bug where the destination address for previously purchased shipping labels was not being displayed to the user.

The root cause was that the config/label-purchase/{order_id} endpoint returns shipping label objects and their corresponding destination addresses in separate parts of the JSON payload. The ShippingLabel model itself did not contain the address, and the app was not performing the necessary association between the two datasets.

This PR introduces a client-side solution to correctly populate the address information:

Enhanced Response Parsing: The app's data models have been updated to correctly parse the selected_destination dictionary from the config.shippingLabelData.storedData path in the API response. The config.shippingLabelData.storedData.selected_destination request parameter was added to obtain the selected_destination payload.
Client-Side Address Mapping: A new mapping mechanism has been implemented. After the config response is decoded, this logic iterates through the currentOrderLabels and injects the correct destination address from the selected_destination dictionary.
Standardized Shipment ID: The address-to-label mapping relies on a standardized shipment_<id> format for the dictionary key. A new WooShippingShipmentIDFormatter utility was created to handle this formatting consistently. It was extracted from the recently added in for reusability WooShippingPackagePurchase.swift
Backward Compatibility: To support labels created before this change (which may not use the new key format), the mapping logic includes a fallback that attempts to look up the destination address using the original, non-formatted numeric shipmentID.

Testing steps

Create a new order with a bunch of physical products. Make it completed.
Split the order into 2+ shipments.
Setup shipments with different hazmat, customs and destination country configurations. For example - the 1st shipment has non foreign destination address, no customs data, but has hazmat. The second shipment has foreign destination address and customs data.
Purchase labels for both shipments.
Close order details and then navigate back to this order from order list.
Expand bottom sheet to reveal destination address details.
Check out each fulfilled shipment you've just purchased.
Each shipment should present the correct destination address.
Consider comparing with web behaviour. Web version should display same addresses for those shipments.

Testing information

This PR is thoroughly covered by new automated tests to ensure the mapping logic is correct and to prevent regressions.

WooShippingShipmentIDFormatterTests: A new test file was created to unit test the ID formatting logic, covering various input scenarios.
WooShippingRemoteTests: The existing remote tests were refactored to use the established waitFor and simulateResponse pattern. The new tests validate the end-to-end flow by mocking the loadConfig API call with different JSON fixtures:
- wooshipping-config-with-destinations.json: Simulates a response containing destination addresses and asserts that they are correctly mapped to the label objects.
- wooshipping-config-without-destinations.json: Ensures the app handles responses without destination data gracefully.
- wooshipping-config-with-invalid-destinations.json: Confirms that a malformed selected_destination object (i.e., an array instead of a dictionary) does not cause a crash.

I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

wpmobilebot · 2025-07-03T23:09:28Z

📲 You can test the changes from this Pull Request in WooCommerce iOS Prototype by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce iOS Prototype
	Build Number	`30991`
	Version	`PR #15866`
	Bundle ID	`com.automattic.alpha.woocommerce`
	Commit	`0290290`
	Installation URL	0ft87kphon740

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

dangermattic · 2025-07-04T03:10:21Z

	1 Warning
⚠️	This PR is assigned to the milestone 22.7 ❄️. The due date for this milestone has already passed. Please assign it to a milestone with a later deadline or check whether the release for this milestone has already been finished.

	1 Message
📖	This PR contains changes to `RELEASE-NOTES.txt`. Note that these changes won't affect the final version of the release notes as this version is in code freeze. Please, get in touch with a release manager if you want to update the final release notes.

Generated by 🚫 Danger

itsmeichigo

Thank you for fixing this. I tested and confirmed that the fix works with labels created with the correct shipment IDs for hazmat and customs.

The workaround for labels created with invalid shipment IDs didn't seem to work (please see a comment below).

I also see that the origin address is still editable - we would need to use the same solution to parse selected_origin as well. Please feel free to handle that in a separate PR if you prefer.

itsmeichigo · 2025-07-04T03:38:35Z

Modules/Sources/Networking/Model/ShippingLabel/Packages/WooShippingPackagePurchase.swift

    /// shipment ID to set for hazmat and customs form
    var formattedShipmentID: String {
-        Values.shipmentIDPrefix + shipmentID
+        return WooShippingShipmentIDFormatter.formattedShipmentID(shipmentID)


Nit: Values.shipmentIDPrefix is no longer used and should be removed from this file.

itsmeichigo · 2025-07-04T04:00:33Z

Modules/Sources/Networking/Model/ShippingLabel/Shipments/WooShippingConfigResponse.swift

+}
+
+public extension WooShippingLabelData {
+    typealias WooShippingLabelDestinations = [String: WooShippingAddress]


❓ Here the destinations are expected to be a dictionary - but for users who created labels with invalid shipment IDs for hazmat and customs, they get an array instead. Then the parsing for selectedDestinations would fail and the workaround in mapDestinations would not be used. We would need to either parse a fallback property as an array to cover that case, or ignore the case entirely.

@itsmeichigo I didn't implement logic to recover/fallback in case if an array arrives behind selected_destinations. The try?is in the init(from decoder: any Decoder) just to make sure the whole decoding pipeline won't fail. At the moment we're just ignoring selected_destination payload if it's an array.

Regarding the mapDestinations function - the fallback only handles ids without a "shipment_" prefix. I.e. the selected_destination can be a dictionary, but the indexes are just numeric strings.

Thanks for the explanation. I didn't know there was such case that the destinations are returned as a dictionary with numeric IDs. From my testing, I could only see the array case. Is it reproducible or the workaround in mapDestination is just for safety?

Is it reproducible

Yep. Check out the Order #1854 in our shared testing store. Addresses there contain both UUID and numeric keys.

itsmeichigo · 2025-07-04T04:01:08Z

Modules/Tests/NetworkingTests/Remote/WooShippingRemoteTests.swift

+        // Then
+        let config = try XCTUnwrap(result.get())
+        let label = try XCTUnwrap(config.shippingLabelData?.currentOrderLabels.first)
+        XCTAssertTrue(label.destinationAddress.isEmpty)


With the workaround in mapDestinations, we should expect destinationAddress to be not empty.

As I mentioned here. The successful parse means ignoring the invalid payload and not failing the whole json decoding. The destinationAddress is intended to be empty since we are ignoring the invalid payload.

RafaelKayumov · 2025-07-04T15:10:22Z

I removed the redundant static let shipmentIDPrefix = "shipment_". I'm going to handle the origin address issue in a separate PR. Also I'll implement any other specific fallbacks separately when I figure out more details.

itsmeichigo

As mentioned in a comment here, I cannot reproduce the case with destinations returned as a dictionary with numeric keys. But I left a suggestion for decoding selected destination addresses as an array, it works from my testing. Please consider applying that as a workaround for labels created in the previous version.

itsmeichigo · 2025-07-07T03:24:22Z

Modules/Sources/Networking/Model/ShippingLabel/Shipments/WooShippingConfigResponse.swift

+            self.selectedDestinations = try? container.decodeIfPresent(
+                WooShippingLabelDestinations.self,
+                forKey: CodingKeys.selectedDestination
+            )


💡 Since you already added a workaround for when the addresses are returned as a dictionary with numeric keys, we can add a fallback for the array case here:

Suggested change

self.selectedDestinations = try? container.decodeIfPresent(

WooShippingLabelDestinations.self,

forKey: CodingKeys.selectedDestination

)

self.selectedDestinations = {

do {

let selectedDestinationsArray = try container.decode([WooShippingAddress].self, forKey: .selectedDestination)

var dictionary: [String: WooShippingAddress] = [:]

for (index, item) in selectedDestinationsArray.enumerated() {

dictionary[index.description] = item

}

return dictionary

} catch {

return try? container.decodeIfPresent(

WooShippingLabelDestinations.self,

forKey: CodingKeys.selectedDestination

)

}

}()

Implemented in a separate PR: #15876

RafaelKayumov added 8 commits July 4, 2025 01:19

Add storedData.selected_destination query parameter for labels config

c9ef314

Handle empty values for shipping address

191af69

Map destination addresses from shipping labels config response

c51e221

Extract shipment id formatting for reusability

ed2c3d4

Map selected_destination addresses with currentOrderLabels

1219856

Extract address mapping to a separate file

1b7e03e

Fallback to numeric shipment id format

2bcdb3f

Add tests

d2e473f

RafaelKayumov added this to the 22.7 ❄️ milestone Jul 3, 2025

RafaelKayumov added type: bug A confirmed bug. feature: shipping labels Related to creating, ordering, or printing shipping labels. Bug labels Jul 3, 2025

RafaelKayumov added 2 commits July 4, 2025 01:56

Update release notes

bb40a05

Fix linter

a19efa9

RafaelKayumov requested a review from itsmeichigo July 3, 2025 23:21

Base automatically changed from woomob-752-shipping-labels-update-the-format-for-shipment-id-in to release/22.7 July 4, 2025 03:09

itsmeichigo self-assigned this Jul 4, 2025

itsmeichigo reviewed Jul 4, 2025

View reviewed changes

Delete unused constant

0290290

RafaelKayumov requested a review from itsmeichigo July 4, 2025 15:10

RafaelKayumov mentioned this pull request Jul 6, 2025

[Shipping Labels] Fix missing origin address for previously purchased shipping labels #15872

Merged

1 task

itsmeichigo reviewed Jul 7, 2025

View reviewed changes

RafaelKayumov mentioned this pull request Jul 7, 2025

[Shipping Labels] Handle address array in selected_destination and selected_origin #15876

Closed

1 task

RafaelKayumov requested a review from itsmeichigo July 7, 2025 12:39

itsmeichigo approved these changes Jul 8, 2025

View reviewed changes

RafaelKayumov merged commit 2ad8619 into release/22.7 Jul 8, 2025
13 checks passed

RafaelKayumov deleted the WOOMOB-746-fix-purchased-labels-address-fields branch July 8, 2025 08:28

-            self.selectedDestinations = try? container.decodeIfPresent(
-                WooShippingLabelDestinations.self,
-                forKey: CodingKeys.selectedDestination
-            )
+            self.selectedDestinations = {
+                do {
+                    let selectedDestinationsArray = try container.decode([WooShippingAddress].self, forKey: .selectedDestination)
+                    var dictionary: [String: WooShippingAddress] = [:]
+                    for (index, item) in selectedDestinationsArray.enumerated() {
+                        dictionary[index.description] = item
+                    }
+                    return dictionary
+                } catch {
+                    return try? container.decodeIfPresent(
+                        WooShippingLabelDestinations.self,
+                        forKey: CodingKeys.selectedDestination
+                    )
+                }
+            }()

[Shipping Labels] Fix purchased labels not presenting destination address #15866

[Shipping Labels] Fix purchased labels not presenting destination address #15866

Uh oh!

Conversation

RafaelKayumov commented Jul 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Testing steps

Testing information

Uh oh!

wpmobilebot commented Jul 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dangermattic commented Jul 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

itsmeichigo left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

itsmeichigo Jul 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RafaelKayumov commented Jul 4, 2025

Uh oh!

itsmeichigo left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

RafaelKayumov commented Jul 3, 2025 •

edited

Loading

wpmobilebot commented Jul 3, 2025 •

edited

Loading

dangermattic commented Jul 4, 2025 •

edited

Loading

itsmeichigo Jul 4, 2025 •

edited

Loading